Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000107_owner-urn-ietf _Thu Nov 7 14:57:44 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02084 for urn-ietf-out; Thu, 7 Nov 1996 14:57:44 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02077 for <[e-mail]>; Thu, 7 Nov 1996 14:57:34 -0500
Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA24765  (mail destined for [e-mail]); Thu, 7 Nov 96 14:57:01 -0500
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
          id OAA03504; Thu, 7 Nov 1996 14:56:34 -0500 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.7 5/3/96
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: "Gregory J. Woodhouse" <[e-mail]>
Cc: Daniel LaLiberte <[e-mail]>, Keith Moore <[e-mail]>,
        [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
In-Reply-To: Your message of "Thu, 07 Nov 1996 09:47:38 PST."
             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 07 Nov 1996 14:56:33 -0500
Sender: [e-mail]
Precedence: bulk
Reply-To: Keith Moore <[e-mail]>
Errors-To: [e-mail]

> It still seems to me that the issues is one of mechanics. It seems fine to
> specify that the namespaces http:, ftp:, gopher:, etc. are reserved for
> URLs so that a client knows a priori that when it sees
>
> http://foo.bar.com/
>
> it knows it only need  connect to foo.bar.com and retrieve the resource.
> But without doing such a check, the client would have to assume the above
> URI *could* be a URN and attempt to resolve it.

I think there's a problem with terminology here.  We have essentially
two separate efforts going on here: (1) defining what URNs look like
and how they are used, and (2) defining a mechanism for URI
resolution.

1. URNs are a name space with the properties defined in RFC 1737.
Strictly speaking, an http URL can never be a URN, since http as a
name space isn't constrained to have those properties.

2. The URI resolution mechanism isn't limited to URNs -- it can also
be used to resolve many types of URLs.

So in the example above, the client doesn't have to know whether
http://foo.bar.com/ is a URN or not to know if it can resolve the
name.  The client can simply attempt to apply URI resolution to the
URL. If it succeeds, it can use any of the services returned by the
resolution process.  If the URI resolution fails, it can fall back to
talking to the http server at foo.bar.com.

> A separate issue is whether the above URI could represent different
> resources when interpereted as a URL or a URN.

A URI is either a URL or URN or something; it cannot be both a URL or
a URN.  As for "interpretation" of an http URL under URI resolution,
this isn't a problem: a URL beginning with "http:" will always be
resolved the same way.

Of course it is "possible" for the resource pointed to by a URL and
the resource you get from resolving that URL with URI resolution will
be different.  But this is no different from the situation we have
today -- if the domain in a URL has multiple IP addresses pointing to
multiple servers and those servers are not in synch.


> Finally, a possible design is to have the above URI be both a URL and a
> URN. By this, I mean that whatever service is responsible for resolving URNs
> will recognize and deal appropriately with namespaces such as http:. But it
> is obviously desirable not to have to go through the process of resolving a
> URN just to get back a URL that is identical to the original URN.

Well, this seems wasteful, but I submit that it really is desirable.

The client doesn't know in advance whether resolution is available for
a particular URL; it has to do a DNS lookup (or consult some other
resolution service) to find out.  As long as the client is attempting
to do resolution anyway, it doesn't hurt for the resolution server to
return a single URL - even one that matches the original.  And there
is a major win here -- if the demand for the resource named by the URL
increases, the provider can simply replicate the resource on
additional servers, tell the resolution server about it, and clients
will find them.

> Now, if I'm missing something fundamental, by all means tell me, but this
> seems like a real issue to me. It seems that omitting the urn: prefix would
> not break anything (unless of course a URI is allowed to have different
> referents depending upon whether or not it is a URN), but it may still be
> useful, just as it may be useful to have a url: prefix for URIs that are in
> fact URLs.

I believe the URN: prefix is essential, but not for this reason.  As
I've said before, the difference between URNs and URLs should have
more to do with the properties of each name space than how they are
resolved.  That is, we need similar resolution mechanisms for URNs (to
provide persistence, longevity, global scope) as for URLs (to provide
redundancy, scalability, and fault-tolerance...which are desirable for
URNs as well).

But human beings need to be able to distinguish between a URN and a
URL.  That way, they can tell a stable, persistent resource identifier
from a resource location.  For instance, if you're writing a paper and
you need to put references to other works, those references should be
URNs, rather than URLs, whenever possible.  Advertising a URL for a
resource says nothing about its longevity or persistence; advertising
a URN for a resource is an indication that the URN will always point
to that resource (if the resource is available).

Keith